PRESENTATION 3.4.5 


N91 - 17054 


ADVANCED AVIONICS LABORATORIES 




Space Transportation Avionics Technology Symposium 
Systems Engineering and Integration 
Advanced Avionics Laboratories 

Introduction 

The simulation, development, and verification of advanced avionics systems for 
launch vehicles have become increasingly complex and expensive tasks. In the past, 
launch vehicle manufacturers, subsystem vendors, and customers have independently 
developed specialized laboratories to support their individual needs. This independent 
development has resulted in duplication of facilities, equipment, software, and labor, and 
also has resulted in hardware and software incompatibilities between facilities. As our 
avionics systems move into the 1990's, the laboratory environments in which they are 
developed must keep pace with technology while also contributing to system cost 
reductions. A method for accomplishing these seemingly contradictory goals of flexibility 
and cost reduction is to implement the following Advanced Avionics Laboratory concepts: 

• allow support of differing configurations of avionics for one program or multiple 

programs at a single laboratory facility 

• standardize concepts of operation and interfaces used in laboratories of this type so that 

hardware, software, and results are compatible and may be shared and compared 

between labs 

• provide a suitable proving ground for potentially cost-saving advanced avionics concepts 

such as Fault Tolerance, Integrated Vehicle Health Monitoring, and Adaptive 

Guidance, Navigation, and Control 

A capsule description of these concepts for Advanced Avionics Laboratories was 
presented at the NASA Space Transportation Avionics Technology Symposium (STATS) 
in Williamsburg, VA on November 7-9, 1989. Representatives from each of the major 
NASA centers and the major aerospace contractors were in attendance, resulting in an 
unusual opportunity for interchange on current capabilities and needs for the future. 

This white paper will describe the presentation on Advanced Avionics Labs at 
STATS, present the salient points of the ensuing discussion between attendees, and then 
focus on the necessary areas of concentration in developing the requirements for 
laboratories which will implement the advanced concepts described above. 
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STATS Presentation 


The STATS presentation on Advanced Avionics Laboratories was produced with 
the assistance of the subpanel members and presented in a quad chart format (Figures 1 & 
2). The subpanel members contributing to the generation of these charts were: Bud Gates 
and David Hudson of Martin Marietta, Don Johnson of Boeing, Fred Kuenzel of General 
Dynamics, and Ron White of NASA-Marshall Space Flight Center. The purpose of this 
presentation was to identify the current state-of-the-art in Avionics Laboratories and the 
direction that future Laboratory development should tala to support the major NASA Space 
Transportation programs. 

The primary objective of Advanced Avionics Laboratory development as identified 
in the presentation is to provide a "proving ground" for emerging avionics technologies 
such as: Fault Tolerance; Adaptive Guidance, Navigation, and Control; and Integrated 
Vehicle Health Monitoring. In meeting this main objective, other important considerations 
for new laboratories are to reduce development, validation, and verification costs, to 
encourage resource and data sharing between programs, and to use flexible design and 
interface techniques to allow for future growth and technology improvements. One method 
identified for accomplishing these objectives is to implement a "common core" laboratory 
concept where a central core area with high-cost items may be shared between a number of 
separate program development activities. Each program would have its own separate 
development area adjacent to the central core. The equipment identified for the common 
area might include precision inertial guidance test equipment, optical test and development 
equipment, and graphic display equipment for real-time presentations to large groups. The 
program-specific areas would contain items such as software and hardware development 
workstations, "hot-bench" areas suitable for standalone static subsystem testing, and 
flexible microprocessor-based interface electronics to connect to the core area for real-time 
operations. Standard networking tools such as Ethernet, TCP/IP, NFS, X-Windows, etc. 
would be implemented for non-time-critical data transmission between lab areas. 

A number of technology issues were identified as important to the development of 
these multi-purpose laboratories including: 

• trade-offs between real-time, hardware-in-the-loop capabilities and non-real-time, all 

software simulations 

• development of database technologies to allow data sharing across programs 
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• prov idin g commonality between the modeling/analysis environment and the real-time 

simulation environment 

• defining hardware and software appropriate for common areas vs. program-specific areas 

• providing standalone as well as integrated testing capabilities 

• providing easy reconfiguration capabilities to support varying hardware and software 

requirements 

Candidate programs identified as potentially benefitting from Advanced Avionics 
Laboratories were virtually all major NASA programs including ALS (Advanced Launch 
System), existing Expendable Launch Vehicle Upgrade Programs, Space Shuttle, Shuttle- 
C, National Aerospace Plane, Advanced Upper Stages such as the Space Transfer Vehicle, 
Spacecraft programs including the Advanced X-Ray Astronomic Facility, and the 
Lunar/Mars Initiative. 

A number of past, present, and future milestones in Avionics Laboratory 
development were identified including the AIPS (Advanced Information Processing 
System) demos at C.S. Draper Laboratory through October 1989, planned MPRAS (Multi- 
Path Redundant Avionics Suite) demos in 1990-92, and the ALS Vehicle Avionics 
Simulation Laboratory at NASA/Marshall planned for 1991. 

STATS Discussions 

Following the Quad Chart presentation, a spirited fifteen-minute discussion ensued 
in which the major points of the presentation were debated and amplified. A major point 
was made and re-emphasized that a common laboratory design was needed among the 
NASA centers and the contractors in order to improve communication, data sharing, and 
the validity of comparisons between sites. Currently, isolation of effort between the 
centers is the norm because of a lack of standardization. This isolation results in 
duplication of effort and wasted time and talents. It was stated that avionics laboratories are 
needed most during the development and system integration phases and serious operational 
problems can arise when attempting to use labs for both development and operations such 
as validation and verification. Concern was expressed that the common core idea is good 
in theory, but in reality each program manager will want his own lab dedicated entirely to 
his program. Cultural changes and efficient design will be necessary in order to ease this 
concern. One point made repeatedly was that the feasibility of the common laboratory 
design concept is highly dependent on the development of common software interfaces and 
models, a difficult technical issue. This issue is particularly a problem with regard to 
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applying standards to programs currently underway such as the Space Shuttle and Space 
Station. One attendee questioned the value of designing a lab to accommodate future 
technology advancements if existing technology works and is efficient The primary thrust 
of the discussion was that Advanced Avionics Laboratories will be a critical part of the 
development of avionics for future NASA programs and vehicles and that major changes in 
the current methods of lab development will be necessary to meet future demands. 

Summary of STATS Activity 

On the day following the Quad Chart presentations for each subtopic, a summary 
session was held for the Systems Engineering and Integration subpanel to determine the 
most useful products of the previous day's discussions. For the Advanced Avionics 
Laboratories subtopic, it was generally agreed that new, multi-purpose labs providing 
common hardware and software interfaces will be needed at each NASA avionics center 
and at each involved contractor. These physically distributed facilities could be connected 
logically to form a "National Avionics Test Facility" similar to the National Test Bed under 
development for the Strategic Defense Initiative. Security considerations would be 
extremely important for such a project but are considered manageable. In order to 
implement the National Avionics Test Facility, the source of funding would have to be 
NASA-wide rather than from any one program. 

Numerous discussions between participants also took place outside the formal 
STATS framework regarding Advanced Avionics Laboratories. A number of participants 
indicated that commonality of operating environments between design, analysis, and lab 
simulations is highly desirable. Ideally, a flight controls analyst should be able to sit at a 
workstation, develop a flight control algorithm, run a software simulation against a realistic 
vehicle model, and then run an actual hardware-in-the-loop simulation for verification 
without having to change his operating environment for each phase of the process. This 
type of commonality could greatly reduce time spent and risk incurred due to interchange 
between groups of analysts, engineers, and programmers all working on different 
computing platforms and in different environments. Although there is no currently 
available single operating environment which can encompass all disciplines efficiently, 
workstation technology is advancing at such a pace that this goal may soon be achievable. 
The key to implementation of this goal is ensuring that hardware and software interfaces are 
well-defined and where flight hardware is in the simulation loop the time constraints 
incurred are not violated. 
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Although Advanced Avionics Laboratories was a separate subtopic at the 
Symposium, there were also discussions concerning advanced laboratories during many of 
the other subtopic presentations. In these other areas the common thread was that advanced 
laboratory environments are necessary in order to develop and prove advanced avionics 
concepts. Examples include the Advanced Processors, Advanced Displays and Controls, 
and Low Cost Avionics subtopics. This widespread recognition of the need for these labs 
emphasizes the importance of the Advanced Avionics Laboratories concepts previously 
discussed. 


Requirements for Multi-Purpose Laboratories 

Cost reduction is the primary factor driving the need for a laboratory supporting 
multiple avionics development efforts. The high-performance simulation and development 
environments needed to support state-of-the-art avionics mandate large investments in 
facilities and high-fidelity test equipment. Development of a "Common Area" housing 
these high-cost items and sharing these items wherever possible between development 
efforts can result in tremendous savings. 

When considering the concept of a laboratory to be used for multiple development 
activities, certain trade-offs must be made in order to determine the functions best suited for 
a common area. One of these trade-offs involves determining when dynamic simulations 
with flight or breadboard hardware in the loop are appropriate. Certain operations will 
require hardware-in-the-loop for fidelity during simulations, particularly inertial 
measurement unit and optical sensor calibration, characterization, and evaluation 
operations. In order to provide a high-fidelity test environment for these systems, a 
seismically stable environment must be provided, generally implemented using massive 
concrete piers isolated from the laboratory structure. To provide a dynamic, flight-like 
environment for the sensors, a three-axis inertial test table is required. Coordinating table 
movement profiles with the sensor data in real time during simulations requires a real-time 
oriented processor with fast input/output capabilities. All of these items are quite expensive 
and large savings can be realized by providing the proper interfacing to allow multiple 
programs to use them on a time-sharing basis. Other operations such as standalone 
subsystem testing and fully software based simulations are more user-specific and require 
smaller investments in equipment and facilities. These program-specific areas could be 
located adjacent to the common core and contain flexible microprocessor-based interface 
electronics to tie them in to the hardware under test in the core. High-cost items necessary 
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for modeling, characterization, and hardware-in-the-loop simulation of avionics 
components include: 

f 

• Seismically quiet environments for IMU evaluation and testing 

• Three-axis inertial test tables and indexing heads for IMU evaluation and testing 

• Real-time hardware-in-the-loop oriented simulation host computers 

• Graphic display systems to aid data interpretation 

• Optical testing environments for star trackers, star scanners, etc. 

• Analysis equipment including spectrum analyzers, signal analyzers, etc. 

Each of these items could be candidates for location in a central core area accessible on a 
time-sharing basis to multiple development efforts. The use of a common core labor force 
able to support hardware-in-the-loop simulations for multiple programs can also result in 
large labor savings. To date, the tasks of configuring a simulation system for real-time 
runs, managing databases, operating the system, and acquiring and reducing data have 
required large staffs, duplicated for each laboratory. Advances in technology will allow 
reductions in the size of this labor force, and a common area implementation will allow 
sharing of the labor cost between programs. An example of a laboratory configuration 
which could support multiple development efforts is shown in Figure 3. 

Benefits From Commonality 

Another factor supporting the development of multi-purpose laboratories is the 
potential benefit from sharing data between related avionics development efforts. 
Typically, avionics laboratories produce tremendous quantities of raw data from 
simulation, and use a large number of personnel to reduce that data and draw results. 
Providing the data and results in a form usable by multiple development activities can also 
result in less duplicated effort. The key component necessary to allow this data sharing 
activity is commonality of software models, databases, and operating environments. In 
addition, common data transfer formats and media between facilities must be provided to 
permit timely data transfers between geographically separated laboratories. 

The real-time control and simulation requirements for particular programs and 
particular disciplines within programs may vary greatly with regard to the hardware 
interfaces to flight-type equipment. For example, a simulation laboratory for an advanced 
expendable launch vehicle may require relatively slow loop rates in the 10-100 Hz range for 
vehicle guidance and control functions, but may require rates of 100-1000 Hz for high- 
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speed engine control and monitor functions. A flexible, expandable real-time interfacing 
architecture is a must for an advanced, multi-purpose avionics laboratory. The real-time 
operating environment should be standardized across geographically separate laboratories 
to ma ximize the validity of data sharing and comparisons between sites. 

Flexibility and Expandability 

In order to provide maximum flexibility and minimize costs due to interface 
incompatibilities, standard hardware and software should be used wherever possible. 
Examples of current standards which may be applicable to the Advanced Avionics 
Laboratory architecture include FDDI, Ethernet, NFS, and TCPIP for networking, X- 
Windows and PHIGS for graphics software, UNIX for workstation operating systems, 
Ada for software development, VMEBus, Multibus, and Futurebus for microcomputer 
backplanes, and the Mil-Std-1553B avionics bus. 

The hardware and software architecture must be modularized to the greatest extent 
possible to provide expandability and adaptation to future changes in requirements. The 
central host computer, graphics workstations, and interface electronics must all have a 
modular design in order to accommodate anticipated changes in requirements for the 
number and types of processors, number and types of hardware interfaces, Input/Output 
bandwidth and communications bandwidth. To provide true flexibility of operations, each 
program's facility and the subsystems within must be able to operate independently of the 
others. To meet this goal, each facility must contain a certain amount of development 
capability as well as the operational interfaces to connect it to the Common Core Area. The 
software architecture for the labs must also be modularized with the goal of providing rapid 
prototyping capabilities. Easy transitions from software simulations to simulations with 
various configurations of flight-type hardware will greatly enhance the efficiency and 
productivity of the laboratory. 


Special Considerations 

Certain special considerations are necessary when defining the electronics for a real- 
time simulation facility which will contain hardware in the control loops and will be used to 
support multiple development efforts. These special considerations have a great deal of 
impact on the overall system architecture, particularly with regard to inter-computer 
communications and connections from computer-based controllers to simulated flight 
hardware, breadboards or actual flight articles. 
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Software-Based Simulations 


Full software simulations of complex electromechanical control systems are 
possible using the quickly evolving high speed families of desktop workstations. These 
stations can perform extremely high definition simulations and have become the 
workhorses for Computer Assisted Design/Computer Assisted Engineering (CAD/CAE) 
applications. The operating system of choice on most high performance workstations is 
UNIX, providing a high degree of portability for applications. UNIX is flexible, powerful, 
and capable of handling the most difficult simulation problems. The drawback to using a 
UNIX-based engine for simulation is its inability to operate in real-time and control actual 
hardware. This however is generally not a problem during the initial system, component, 
and algorithm development stages. High definition graphics output, coupled with the 
workstations' power to solve complex math-intensive problems, allows the control systems 
designer to see the results of changing control algorithms, plant dynamics, and other 
control critical parameters without having to deal with cumbersome pieces of hardware and 
test equipment. 


Hardware-In-The-Loop 

When simulations are performed completely in software without hardware 
stimulation and response, synchronization of the various parts of the simulation is not a 
time-critical concern and the phase relationship between various operations may be 
controlled with relative ease. The introduction of hardware into a control system simulator 
brings with it a whole new family of problems. Hardware-in-the-loop simulations are 
generally time and phase critical and must be closely synchronized to the digital control 
processors used to close the loops. Deterministic control algorithms must be designed to 
insure that timing errors such as control frame overruns can not occur. The hardware must 
be designed to minimize latency of responses to external events and to insure that no 
undefined timing jitter will be added by the interfaces. Any timing uncertainties induced by 
algorithms or hardware will result in undesirable phase errors and time aliasing creeping 
into the control loops. These types of errors will result in the inability to time correlate 
multiple control loops and will cause unreliable test results and output data. 
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Embedded Controllers 


The design of true real-time control system hardware requires the design of 
dedicated interface electronics with embedded microprocessor controllers. These dedicated 
interfaces provide the wide I/O bandwidths and high-speed mathematics necessary to close 
robust precision servo loops. Hardware-In-The-Loop Simulations require very high 
bandwidth local control loops to ensure sufficient phase margins for an unconditionally 
stable system. These types of local loops generally require embedded controllers running at 
control loop frequencies 10 to 100 times faster than the host computer loop frequencies. 
The embedded controllers are typically responsible for the mathematics required to 
compensate local control loops, such as State Variable Control and Proportional, 
Integrator, Differentiator (PID) types of compensators. Wide bandwidth dedicated buses 
are used to ensure that data is always available to the processors and to the actuators at the 
same time in each frame. This guarantees that there will be no timing inconsistencies to 
cause loop overrun errors or time aliasing. Fast interprocessor communications are required 
for concurrent algorithm processing. Intermediate control variables to be passed from 
controller to controller or to the data logger interface are passed on this type of interface. 

Analog Interfaces 

In order to provide extremely accurate and reliable control of sensor and actuator 
interfaces, precise and noise-free analog interfaces must be implemented. To provide the 
maximum noise immunity for analog signals, a low impedance balanced differential signal 
path must be used and the physical distance between drivers and receivers must be 
minimized. When these guidelines are followed, accuracies of up to 15 bits during D/A 
and A/D conversions may be attained. This level of accuracy will allow precise control of 
actuators and minimiz e jitter due to quantization noise. The sampling and command rates 
for all servo hardware must be completely synchronous and phase-locked. A flexible 
scheme of distributing a hardware synchronization pulse to the remote analog and digital 
data acquisition electronics and the controlling computer systems must be implemented. 
The hardware synchronization system should be capable of providing phase-locked 
synchronization pulses throughout the system at frequencies varying from 10 Hz to 10 
KHz. Where possible, sensors should be sampled at a rate ten times the command 
frequency in order to maximize the phase margin for each control loop. Anti-aliasing filters 
must be implemented for each sensor input and data smoothing filters for each actuator 
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output to eliminate aliasing errors and undesired high-frequency signal components. 
Power for the hardware under test should be isolated as much as possible from the 
electrically noisy computer environment in order to provide maximum noise immunity. 
This may be accomplished by means of fiber optic data links and opto-isolators at critical 
interfaces. As stated above, distribution of analog signals should be by means of 
differential amplifiers and receivers wherever possible. 

Host Computer 

Typically, a real-time simulation laboratory will require the use of a modem high 
speed, multiple processor, concurrent algorithm computer. This computer will handle the 
high level mathematics, simulation control, and man-machine interfaces for the entire 
laboratory complex. The real-time frame rate for the host machine will generally be from 10 
to 100 times slower than the rate for the the local control processors. The host will be 
required to handle most of the mathematics associated with the equations of motion and will 
be required to solve math intensive problems including rigid and flexible body mechanics. 
The host computer must be capable of very wide I/O and interprocessor backplane 
bandwidths. Data must be passed to and from local control processors quickly in order to 
avoid an adverse impact on the processing time available to the local controllers. Data and 
intermediate control variables must also be passed between CPUs inside of the host 
computer system to allow for interaction between concurrently operating servos and 
algorithms. 


Summary 

In order to develop the new generation of avionics which will be necessary for 
upcoming programs such as the Lunar/Mars Initiative, Advanced Launch System, and the 
National Aerospace Plane, new Advanced Avionics Laboratories are required. To 
minimize costs and maximize benefits, these laboratories should be capable of supporting 
multiple avionics development efforts at a single location, and should be of a common 
design to support and encourage data sharing. Recent technological advances provide the 
capability of letting the designer or analyst perform simulations and testing in an 
environment similar to his engineering environment and these features should be 
incorporated into the new laboratories. Existing and emerging hardware and software 
standards must be incorporated wherever possible to provide additional cost savings and 
compatibility. Special care must be taken to design the laboratories such that real-time 
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hardware-in-the-loop performance is not sacrificed in the pursuit of these goals. A special 
program-independent funding source should be identified for the development of Advanced 
Avionics Laboratories as resources supporting a wide range of upcoming NASA programs. 
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